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(57) Abstract: The invention concerns a method for loading an applet in a smart card (2a), using two loading programmes, a so-called 
In-loader (IL), stored in the card, and Off-loader, respectively. The invention is characterised in that two specific communication 
protocol layers are provided, one in a terminal (1) hosting the card reader, the other in the card. Said layers include in particular 
intelligent agents enabling the card to provide a WEB client/server and a CGI gateway functional capability. The method comprises 
at least one step during which a HTTP request is sent to the card, to address a HTML page, a step which consists in retrieving pa- 
rameterising data transported by a HTML form and a step which consists in executing a second loading programme (IL) using the 
CGI functional capability to load the applet. 

(57) Abrigt : L'invention conceme le chargement d'une "applet" dans une carte h puce (2a), ^ Taide de deux programmes de char- 
gement, dits "In-loader" (EL), stocks dans la carte, et "Off-loader" (OL), respectivement. Selon Tinvention, on pr^voit deux couches 
protocolaires de communication sp^Hques, Tune dans un terminal (I) h^bergeant le lecteur de la cane, Tautre dans la carte. Ces 
couches comprennent notamment des agents intelligents permettant k la carte d'offrir une fonctionnalit^ de client/serveur "WEB" et 
de passerclle "CGI**. Le proc^dfi comprend au moins une dtape pendant laquelle une requfile '*HTTP" est envoy6e d la carte, pour 
adresser une page "HTML", une €tape de recuperation de donnees de param6trage v^hicuides par un fonmulaire "HTML" et une 
eiape d*execulion du second programme de chargement (£L), par mise en oeuvre de la fonctionnaiite "CGI", pour charge 1* "Applet". 
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En ce qui conceme les codes a deux lettres et autres abrevia- 
tions, se riftrer aux "Notes expHcatives relati^fes aux codes et 
abreviations" figurant au debut de cheque numero ordinaire de 
la Gazette du PCT 



wo 01/59563 



PCT/FROl/00393 



PROCEDE DE CHARGEMENT D UNE PIECE DE LOGICIEL DANS UNE 
CARTE A PUCE, NOTAMMENT DU TYPE DIT "APPLET" 



Linvention concerne un procede de chargement d'une piece de 
logiciel dans une carte a puce. 

Elle s'applique plus particulierement au chargement d'une piece de 
5 logiciel appel§e en frangais "appliquette", plus connue sous le terme anglo- 
saxon d* "applet". II s'agit d*une application ecrite en langage "JAVA" 
(marque depos6e). Ces applications, generalement peu volumineuses, sont 
independantes des architectures des systemes sur lesquelles elles sont 
implantees. Elles peuvent done fonctionner sur n'importe quel systeme 
10 informatique, dans la mesure ou celui-ci implemente le concept dit de 
"machine virtuelle JAVA" ("Java Virtual Machine"). Une application ecrite en 
langage JAVA est en general traduite en un langage intermediaire dit "Byte 
Code". La machine virtuelle JAVA precitee constitue un interpretateur de ce 
"Byte Code", de manidre a etre executee directement sur un systeme cible, 
15 hote de ladite machine virtuelle. 

Generalement, les architectures de systeme sur lesquelles tourne 
ce type d'applications sont du type dit client-serveur. Dans ce cas, on parte 
egalement de "servlet" pour une application stockee sur un systeme sen/eur 
et "applet" pour une application stockee sur un systeme client. Dans ce qui 
20 suit, on utilisera le terme "applet" de fagon generique. 

Des pieces de logiciel, se presentant sous la forme d* "applet" qui 
vient d'etre rappelee, dans la mesure ou la quantity de code n'est pas trop 
volumineuse, peuvent etre stockees dans une memoire non volatile presente 
sur une carte a puce, au meme titre que toute autre application. 
25 Aussi, le proc6de selon Tinvention est plus particulierement 

concerns par un terminal ou station d'utilisateur muni d'un lecteur de carte k 
"puce". 
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Dans le cadre de I'invention, le terme "terminar doit etre compris 
dans un sens general. Le terminal precite peut etre notamment constitu6 par 
un ordinateur personnel fonctionnant sous divers systemes d'exploitation, 
tels WINDOWS ou UNIX (tous deux etant des marques deposees). II peut 
5 §tre aussi constitue par une station de travail, un ordinateur portable ou un 
terminal de carte dit d6di§. 

Dans r^tat actual de la technique, le chargement d'une "applet** sur 
une carte a puce (encore appele tel6chargement) se fait grace a deux 
programmes specifiques. Ces programmes sont generalement connus sous 
10 les termes anglo-saxons "Off-Loader", pour le premier, et "In-Loader**, pour 
le second. Le programme "Off-Loader" s'execute sur le terminal et le 
programme "In-Loader" s'execute dans la carte a puce. Les programmes de 
chargement "Off-Loader" et "In-Loader" communiquent entre eux au travers 
d'une liaison normalisee de type ISO 7816-3, protocole universellement 
15 retenu pour les communications entre une carte k puce et son terminal hote. 
Ce protocole met en oeuvre une suite d*6changes g6neralement 
proprietaires (commandos d*un type dit "APDU" qui seront explicitees ci- 
apr§s) afin de realiser le chargement d*une "applet". 

La figure 1A annexee a la presente description illustre de fagon 
20 schematique Tarchitecture mise en oeuvre pour le chargement d* "applets" 
dans une carte a puce selon Tart connu. 

Le terminal 1 stocke un premier programme specifique de 
chargement ("Off -Loader"), reference OL. II communique avec une carte ^ 
puce 2, via un lecteur de carte a puce 3. Les transmissions s'effectuent selon 
25 un protocole de communication normalise, faisant appel aux commandos 
precit^es, protocole qui sera detaille ci-apr§s. 

La carte a puce 2, pour sa part stocke un second programme 
sp§cifique de chargement ("In-Loader"), reference IL. 

Un premier inconv6nient de ce proc6d6 est que les programmes IL 
30 et OL doivent etre apparies pour pouvoir communiquer entre eux. II s'ensuit 
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que s'ils sont d'origines differentes, ils ne sont pas. a priori, compatibles. 
Cette caract6ristique est liee au jeu de commandes a utiliser. 

Un deuxieme inconvenient est du au fait que les communications 
s'effectuent selon le protocole ISO 7816 precite. En effet, celui-ci impose une 
5 proximity physique entre les programmes OL et IL. II s'ensuit que le 
programme OL doit generalement s'ex6cuter directement sur le terminal 1 et 
non, par exemple, sur un autre terminal ou un serveur eloign6. 

Or, avec I'essor spectaculaire du reseau Internet, un nombre 
toujours croissant de terminaux sont connectes a ce r§seau, notamment 
10 pour pouvoir etre en liaison avec des serveurs eloignes, de type "WEB". II 
serait done interessant, par exemple, de pouvoir stocker la partie "Off- 
Loader" OL des programmes de chargement d' "applets" sur un serveur 
"WEB" connecte a ce reseau. Les "applets" a charger sur une ou plusieurs 
carte{s) a puce pourraient d'ailleurs etre aussi stockees sur ce serveur ou 
15 sur un ou plusieurs autres serveurs de ce type. 

Dans Tetat actuel de la technique, ce mode operatoire bute sur une 
double impossibilite. La premiere a deja ete evoquee : la norme retenue pour 
les communications entre le terminal et la carte a puce impose a priori une 
proximit6 physique entre la localisation des programmes "Off-Loader", OL, et 
20 "In-Loader". IL. 

□'autre part, les transmissions entre deux systemes, par exemple 
un terminal et un serveur eloigne, via le reseau Internet, font appel a des 
protocoles de type Internet. Dans Tetat actuel de la technique, il n'est pas 
possible de realiser des communications directes entre une carte k puce et 
25 le reseau Internet, comme il va I'etre explicit§ egalement. 

Dans le cadre de I'invention, le terme "reseau Internet" englobe, 
outre le reseau Internet proprement dit, les reseaux prives d'entreprises ou 
similaires, du type dit "intranet", et les reseaux les prolongeant vers 
rexterieur. du type dit "extranet", et de fagon g§n§rale tout r§seau dans 
30 lequel les ^changes de donnees s*effectuent selon un protocole du type 
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Internet. Dans ce qui suit un tel r§seau sera appel6 de fagon g^n^rique 
•Yeseau Internet". 

On va tout d'abord rappeler brievement Tarchitecture generale d*un 
systeme d'application a base de carte a puce, relie a un reseau Internet, par 
5 reference aux figures 1 B et 1 C. 

Un systeme d*application a base de carte a puce comporte 
generalement les el§ments principaux suivants : 
une carte a puce ; 

un systeme hote constituant le terminal precite ; 
10 ' un reseau de communication, a savoir le reseau Internet dans 

rapplication prefer6e ; 

et un serveur d'application connecte au reseau Internet. 
La figure 1B illustre schematiquement un exemple d'architecture de 
ce type. Le terminal 1, par exemple un ordinateur individuel, comporte un 
15 lecteur 3 de carte a puce 2. Ce lecteur 3 peut etre ou non physiquement 
int§gr§ dans le terminal 1 . La carte a puce 2 comporte un circuit integre 20 
dont des connexions d'entrees-sorties affleurent en surface de son support 
pour autoriser une alimentation en 6nergie 6lectrique et des communications 
avec le terminal 1 . Ce dernier comprend des circuits d'acces 1 1 au reseau 
20 Internet/?/. Ces circuits peuvent etre constitu6s par un modem pour se 
connecter a une ligne telephonique commutee ou a une voie de 
communication a plus haut debit : reseau numerique a integration de 
services ("RNIS"), cable ou liaisons par satellite, etc. Les circuits 11 
permettent de se connecter au reseau Internet /?/, directement ou via un 
25 prestataire de sen^ices Internet ("Internet Sen/ice Provider" ou "ISP", selon la 
terminologie anglo-saxonne). On peut egalement avoir recours a un systdme 
interm6diaire tel qu'un "proxy" ou un systeme desolation dit "firewall" ("pare- 
feu" ou encore appel§ "garde barriere"). 

Le terminal 1 comprend naturellement tous les circuits et organes 
30 nfecessaires a son bon fonctionnement, et qui n'ont pas 6te representes 
dans un but de simplification du dessin : unite centrale, memoires vive et 
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fixe, m6molre de masse d disque magn6tique, lecteur de disquette et/ou de 
CedeRom, etc. 

Habituellement, fe terminal 1 est aussi reli6 a des peripheriques 
classiques. integres ou non. tels un ecran de visualisation 5, un clavier 6a et 
5 une sourls 6b, etc. 

Le terminal 1 peut etre mis en communication avec des serveurs ou 
tous systemes informatiques connect6s au reseau /=?/, dont un seul, 4, est 
illustre sur la figure 1A. Les circuits d'acces 11 mettent le terminal 1 en 
communication avec les serveurs 4 gr§ce a un logiclel particulier 10. appel6 
10 navigateur "WEB", ou "browser** selon la terminologie anglo-saxonne. Celui- 
ci permet d'acceder a diverses applications ou fichiers de donnees repartis 
sur I'ensemble du reseau /?/. generalement selon un mode "client-serveur". 

Habituellement. les communications sur les reseaux s'effectuent 
conformement a des protocoles repondant a des standards comprenant 
15 plusieurs couches logicielles superposees. Dans le cas tfun reseau Rl de 
type Internet, les communications s'effectuent selon des protocoles 
sp§cifiques a ce type de communications, qui seront detailles cl-apres. mais 
qui comprennent 6galement plusieurs couches logicielles. Le protocole de 
communication est choisi en fonction de I'application plus particulierement 
20 visee: interrogation de pages "WEB", transferts de fichiers, courrier 
6lectronique (e-mel, ou "e-mail" selon la terminologie anglo-saxonne), 
forums ou "news", etc. 

^architecture logique du systeme comprenant un terminal, un 
lecteur de carte a puce et une carte a puce, est representee 
25 schematiquement par la figure 1C. Elle est d§crite par la norme ISO 7816, 
qui elle-meme comportent plusieurs sous-ensembles : 

ISO 7816-1 et 7816-2, en ce qui concerne les dimensions et le 
marquage des cartes ; 

ISO 7816-3, en ce qui conceme le transfert de donndes entre 
30 le temiinal et la carte a puce ; et 
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ISO 7816-4, en ce qui conceme la structure du jeu d'ordres et 
le format des commandes. 

Sur la figure 1C, du cote terminal 1, on n'a represents que les 
couches repondant k la norme ISO 7816-3, ref§rencees 101, et un 
5 gestionnaire d'ordres "APDU" (norme ISO 7816-4), reference 102. Du c6t6 
carte a puce 2, les couches repondant i la nomie ISO 7816-3 sont 
r6f6rencees 200 et le gestionnaire d'ordres "ADPU" (norme ISO 7816-4) est 

r§ferenc§ 201 . Les applications sont referencees >\i Ai,...,An;n etant le 

nombre maximum d'applications presentes sur la carte a puce 2. 

10 Une application. A,; presente dans la carte a puce 2, dialogue avec 

le terminal 1 au moyen d'un jeu d'ordres. Ce jeu presente typiquement des 
ordres d'Scriture et des ordres de lecture. Le format des ordres est connu 
sous I'abreviation anglo-saxonne de "APDU" (pour "Application Protocol 
Data Unit"). II est d^fini par la norme ISO 7816-4 pr§cit§e. Une "APDU" de 

15 commande est notee "APDU.commancT et une "APDU" de r§ponse est 
not§e "APDU. response''. Les "APDU" sont 6chang6es entre le lecteur de 
carte et la carte a puce au moyen d'un protocole specific par la nornie ISO 
7816-3 pr6citee (par exemple en mode caract6re : T=0 ; ou en mode bloc : 
T=1). 

^0 Lorsque la carte a puce 2 inclut plusieurs applications distinctes, 

comme illustre sur la figure 1C, on parle de carte multi-applicative. 
Cependant, le terminal 1 ne dialogue qu'avec une seule application k la fois. 
Une application Ai se presente, par exemple, sous la forme d'une "applet" 
qui peut etre enregistree initialement, ou encore chargee a partir du terminal 

25 1. Pour ce faire, comme illustr6 par la figure 1A, on a recours a un 
programme "Off-Loader", OL, enregistre dans le terminal 1 et ^ un 
programme "In-Loader", IL, qui fomie I'une des applications A; de la carte a 
puce 2. 

La selection d'une application particuliere Aj est obtenue a I'aide 
30 d'une "APDU" du type selection ("SELECT"). Une fois ce cfioix effectue. les 
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"APDU" qui le suivent sont achemines vers cette application. Une "APDU 
SELECT" nouvelle a pour effet d'abandonner I'application en cours et d'en 
choisir une autre. Le sous-ensemble logiciel gestionnaire des "APDU" 201 
permet de choisir une application particulidre A\ dans la carte a puce 2, de 
5 m^moriser I'application ainsi cholsie, et de transmettre et/ou recevoir des 
"APDU" vers et depuis cette application. 

En resume de ce qui vient d'etre decrit, la selection d'une 
application /»/ et le dialogue avec celle-ci s'effectuent par echanges d'ordres 
"APDU". On suppose que les applications Aj sont des applications 

10 conventionnelles, que Ton appellera ci-aprds "GCA" (pour "Generic Card 
Application" ou application de carte g^nerique). 

Ce mode operatoire explique que les programmes OL et IL doivent 
etre appari§s, pour que les ordres "APDU" echanges puissent etre 
compatibles et compris par ces deux applications. 

IS Ces rappels §tant effectu6s, II est k noter que la carte d puce 2 ne 

peut communiquer directement avec les navigateurs standards du 
commerce, sauf a modifier le code de ces derniers. 

En outre, et surtout, les cartes a puce actuelles, qui par ailleurs sont 
conformes aux standards et normes rappel§s ci-dessus, onl une 

20 configuration materielle et logicielle qui ne permet pas non plus de 
communiquer directement avec le r6seau Internet. En particulier, elles ne 
peuvent recevoir et transmettre des paquets de donn§es, selon I'un ou 
I'autre des protocoles utilises sur ce type de reseau. II est done necessaire 
de prevoir une piece de logiciel additionnelle, implantee dans le terminal 1, 

25 g§neralement sous la forme de ce qui est appel6 un "plug-in", selon la 
termlnologie anglo-saxonne. Cette pidce de logiciel, qui porte la reference 12 
sur la figure IB, effectue interface entre le navigateur 10 et la carte 2, plus 
precisement les circuits electroniques 20 de cette carte 2. 
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L'invention vise a pallier les inconvenients des precedes et 
dispositifs de Tart connu, et dont certains viennent d'etre rappeles, tout en 
repondant aux besoins qui se font sentir. 

Selon une premiere caracteristique de rinventlon, les deux 
5 programmes de chargement, OL et IL ne sont plus dependants Tun de 
Tautre. En d'autres termes. ils n'ont plus a etre apparies pour etre 
compatibles. 

Selon une deuxieme caracteristique de Tinvention. la partie OL des 
programmes de chargement n'a plus a etre stockee obligatoirement dans le 

10 terminal, c*est-a-dire en relation de proximite physique avec la seconde 
partie IL. Tout au contraire, le programme OL peut etre stocke sur un 
serveur eloigne, connecte au terminal via un reseau de type Internet. 

Pour ce faire, et selon une autre caracteristique de Tinvention, la 
carte a puce se comporte comme un serveur/client de type "WEB" pour le 

15 terminal qui lui est associ§. 

Pour atteindre ce but, on prevoit une couche de logiciel de 
communication specifique dans la carte a puce et son pendant dans le 
terminal. Le terme "specifique" doit etre entendu comme specifique au 
proc6d§ de Tinvention. En effet. ces couches de communications, dites 

20 sp§cifiques, sont banalisees quelle que soit Tapplication consideree. Elles 
n'interviennent que dans le processus d'echanges de donnees 
bidirectionnels entre la carte a puce et le terminal, d'une part, et la carte a 
puce et le reseau, d'autre part. 

Les couches logicielles de communication specifiques comprennent 

25 notamment des composants logiciels. dits "agents intelligents". permettant 
en particulier des conversions de protocoles. Les agents intelligents seront 
appeles ci-apres plus simplement "agents". II existe des agents appareilles 
dans les couches de communication sp6cifiques respectives associees au 
terminal et a la carte a puce. Selon le precede de Tinvention, il s'etablit des 

30 sessions entre agents appareilles. 
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Selon une au:re caracteristique, te proc§de de Tinvention rend 
possible I'activation d'appHcations de type conventionnel. c'est-a-dire du type 
"CGA" precite, localisees dans une carte a puce, sans devoir les modifier en 
quoi que ce soit. 

5 Pour ce faire. on prevoit un ou plusieurs agents intelligents 

particuliers dits traducteurs de script, qui resolvent des requetes d*un 
navigateur et les traduisent en ordres "APDU" comprehensibles par 
I'application de type "CGA". De ce fait, on implante dans la carte a puce une 
fonction similaire a celle connue par ailleurs sous la denomination "CGI" 
10 dans les serveurs "WEB" classiques. Cette fonction permet de mettre en 
oeuvre une application dans la carte a puce par un protocole Internet de type 
"HTTP". 

Le chargement d'une "applet" dans la carte a puce peut s'effectuer 
par cette interface "CGI". La partie IL du programme de chargement est 

15 considere comme etant un script de commandes, que Ton appellera "cgl- 
script", attache a la fonctionnalite serveur "WEB" offerte par la carte a puce. 
Les echanges entre les programmes OL et IL peuvent se derouler avec 
Taide de formulaires classiques en langage "HTML" ou "forms" selon la 
terminologie anglo-saxonne. 

20 Tout en conservant les normes ISO pr6citees pour les 

communications entre terminal et carte a puce, via le lecteur de carte d 
puce, le procede selon I'lnvention permet des ^changes entre les parties de 
programmes de chargement OL et IL en faisant appel au protocole de 
communication Internet "TCP/IP", la partie OL et les "applets" a charger 

25 pouvant etre stockees en local ou dans un serveur eloigne. 

L'invention a done pour objet principal un proc6d6 de chargement 
d'une pidce de logiciel dans une carte a puce a partir d*un terminal connects 
a ladite carte a puce par I'intermddiaire d'un lecteur de carte a puce 
permettant des communications selon un premier protocole determine, ledit 
30 chargement s'effectuant par la mise en oeuvre et la cooperation de premier 
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et second programmes de chargement, ledit second programme de 
chargement etant stocke dans ladite carte a puce, caracterise en ce quil 
comprend au moins les phases suivantes : 

a/ une premiere phase preliminaire consistant a implanter, dans 
5 ladile carte a puce, une premiere piece de logiciel, formant une couche 

protocolaire de communication specifique ; 

b/ une deuxieme phase preliminaire consistant a implanter, dans 
ledit terminal, une seconde piece de logiciel, formant une couche 
protocolaire de communication specifique ; 
10 en ce que lesdites premiere et seconde pieces de logiciel comprennent 

en outre au moins une paire de premieres entites logicielles appari^es, 
chacune desdites entites cooperant Tune avec Tautre de manidre a 
permettre Tetablissement d'une session d'echanges de donnees 
bidirectionnels entre au moins ledit terminal et ladite carte a puce, de 
15 maniere a ce que ladite carte k puce offre la fonctionnallte d'un client/serveur 
"WEB- ; 

en ce qu'il comprend une troisieme phase preliminaire consistant a 
implanter dans ladite carte a puce au moins une deuxieme entite logicielle. 
apte a interpreter une suite d'instructions et a la traduire en une suite 
20 d'ordres, de maniere a cooperer avec ladite seconde piece de logiciel 
specifique pour que ladite carte a puce offre une fonctionnallte d'lnterface 
passerelle dite "CGI", la dite carte a puce comprenant au moins une desdites 
suites d*instructions associee au dit second programme de chargement ; 
et en ce qu'il comprend au moins les etapes suivantes : 
25 1/ ouverture d'une premiere session d'echanges de donnees 

entre au moins ledit terminal et ladite carte a puce, pour la transmission 
d'une requete pour que ledit premier programme de chargement 
recupere des donnees de parametrage de chargement fournies par 
ledit second programme de chargement ; 



WO01/595d3 



PCT/FROl/00393 



11 

21 ouverture d'une deuxieme session d'echanges de donn6es 

entre ladite carte k puce et au moins ledit terminal pour transmettre 
lesdites donnees de parametrage de chargement au dit premier 
programme de chargement, lesdites donnees de parametrage 
5 comportant une reference aux dites instructions associees au dit 

second programme de chargement ; et 

3/ ouverture d*une troisieme session d'echanges de donnees 
entre au moins ledit tenninal et ladite carte a puce, pour la soumission d*un 
fichier de chargement prenant en compte lesdites donn§es de parametrage 
10 de chargement, ledit fichier comprenant des donnees representant ladite 
piece de logiciel k charger; interpretation de ladite suite d'instructions 
associ^e au dit second programme de chargement, par mise en oeuvre de 
ladite fonctionnalit§ "CGI", de maniere generer une suite d'ordres transmise 
au dit second programme de chargement, a executer ce programme et a 
15 obtenir ledit dechargement de ladite piece de logiciel. 

L'invention va maintenant etre decrite de fagon plus detaillee en se 
r6ferant aux dessins annexes, parmi lesquels : 

la figure 1 A illustre schematiquement un exemple de realisation 
d'une architecture permettant le chargement d'une "applet" dans une 
20 carte a puce selon Tart connu ; 

les figures IB et 1C illustrent les architectures materielle et 
logique, respectivement, d'un exemple de systeme d'application a 
base de carte a puce connecte a un reseau Internet selon Tart 
connu. ; 

25 ' la figure 2 illustre schematiquement un exemple de systeme 

d'application a base de carte a puce selon Tinvention, cette dernidre 
agissant en tant que client/serveur "WEB" ; 

la figure 3 est un diagramme d'etats d'une session entre des 
entit^s logicielles dites agents intelligents, selon un aspect de 

30 l'invention ; 
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la figure 4 illustre de fagon simplifiee Tarchitecture logique d'un 
systeme selon I'invention dans lequel la carte a puce comprend des 
agents intelligents ; 

la figure 5 illustre de fagon simplifiee Tarchitecture logique d'un 
systeme selon invention dans lesquels la carte a puce comprend 
des agents intelligents traducteurs de scripts ; 

la figure 6 illustre schematiquement un exemple de realisation 
d'une architecture permettant le chargement d'une "applet" dans une 
carte ^ puce selon Tinvention ; 

- la figure 7 illustre la structure d'un fichier de chargement d'une 

"applet" pouvant etre en oeuvre par le precede selon Tinvention ; 
la figure 8 illustre schematiquement les phases principales du 

proc6de de chargement d*une "applet" dans une carte a puce selon 

un premier exemple de realisation pratique ; 

la figure 9 illustre schematiquement les phases principales du 

proced6 de chargement d'une "applet" dans une carte a puce selon 

un deuxieme exemple de realisation pratique ; 

les figures 9 et 10 illustrent deux exemples de formulaires en 

langage "HTML" utilisables par le precede de chargement d'une 

"applet" dans une carte a puce selon Tinvention, pour la mise en 

oeuvre des methodes dites "GET" et "POST", respectivement ; et 
les figures 12A a 12G illustrent plusieurs variantes de 

realisation de realisation d'architectures de systemes permettant le 

chargement d'une "applet" dans une carte a puce selon I'invention. 

Dans ce qui suit, sans en limlter en quoi que ce soit la portee, on se 
placera ci-apr§s dans le cadre de Tapplication pref6ree de {'invention, sauf 
mention contraire, c'est-a-dire dans le cas d'un terminal connecte a un ou 
plusieurs sen/eurs eloign6s via le r6seau Internet. 

Avant de decrire le proced§ deactivation d'applications localisees 
dans une carte a puce selon Tinvention et de detainer une architecture pour 
sa mise en oeuvre. par reference a la figure 2, il apparait tout d'abord utile de 
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rappeler brievement los caracteristiques principals des protocoles de 
communication sur les i^seaux. 

L'architecture des reseaux de communication est decrite par 
diverses couches. A titre d'exemple, le standard "OSI" ("Open System 
5 Interconnection"), defini par T "ISO", comporte sept couches qui vont des 
couches dites basses (par exemple la couche dite "physique" qui conceme 
le support de transmission physique) aux couches dites hautes (par exemple 
la couche dite "d'application"), en passant par des couches intermediaires, 
notamment la couche dite de "transport". Une couche donnee offre ses 

10 services a la couche qui lui est immediatement superieure et requiert de la 
couche qui lui immediatement Inferieure d'autres services, via des interfaces 
appropriees. Les couches communiquent a I'aide de primitives. Elles 
peuvent egalement communiquer avec des couches de meme niveau. Dans 
certaines architectures, plusieurs couches peuvent etre inexistantes. 

Dans un environnement de type Internet, les couches sont au 
nombre de cinq, et de fagon plus precise, en allant de la couche superieure 
a la couche inferieure : la couche dite d'application ("http", "ftp", "e-mail", 
etc.). la couche dite de transport ("TCP"), la couche dite d'adressage de 
reseau ("IP"), la couche dite de liens de donnfees ("PPP", "Slip", etc.) et la 

20 couche dite physique. 

Si on se reporte de nouveau a la figure 2, ^ I'exception de couches 
logicielles de protocole de communication specif iques, rdferencees 13 et 
23a, respectivement implantees dans le terminal 1 et la carte a puce 2a, les 
autres elements, materiels ou logiciels, sont communs a Tart connu, et il n'y 

25 a pas lieu de les re-d6crire de fagon detaillee. 

Le terminal 1 comprend des circuits 11 d'acces au reseau f?/, 
constitues par exemple d'un modem. Ces circuits regroupent les couches 
logicielles inf6rieures, Ci et C2. qui correspondent aux couches "physique" 
et de "lien de donn6es". 
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On a §galement repr6sent§ les couches sup6rieures, C3 et C4. qui 
correspondent aux couches "d'adressage de reseau" ("IP", dans le cas 
d'Internet) et de "transport" ("TCP"). La couche superieure d'application 
("http", "ftp", "e-mail", etc.) n'a pas et§ representee. 
5 L'interface entre les couches inferieures, Ci et C2, et les couches 

sup§rieures, C3 et C4, est constituee par une couche logicielle 
generalement appelee "driver couches basses". Les couches sup6rieures, 
C3 et C4, s'appuient sur cette interface et sont mises en oeuvre par 
I'intemiedlaire de bibliotheques de fonctions specifiques ou bibliotheques 
10 reseau 14, avec lesquelles elles correspondent. Dans le cas du reseau 
Internet, "TCP/IP" est mis en oeuvre au moyen de bibliotheques dites de 
"sockets". 

Cette organisation permet a un navigateur 1 0 de poser des requetes 
vers un serveur 4, pour la consultation de pages "WEB" (protocole "HTTP"), 

15 pour le transfert de fichiers (protocole "FTP") ou I'envoi de courrier 
§lectronique (protocole "e-mail"), ce de fagon tout a fait classique en sol. 

Le terminal 1 comprend egalement un lecteur de carte 3, integre ou 
non. Pour communiquer avec la carte a puce 2a, le lecteur de carte 30 
englobe egalement deux couches basses, CCi (couche physique) et CC2 

20 (couche de lien de donnees), jouant un role similaire aux couches Ci et C2. 
Les interfaces logicielles avec les couches CCi et CC2 sont d^crites, par 
exemple. par la specification "PC/SC" ("parte, service provider"). Les 
couches elles-m§mes, CCi et CC2, sont notamment d^crites par les normes 
ISO 7816-1 a 7816-4. comma il a ete rappele. 

25 Une couche logicielle supplementaire 16 forme interface entre les 

couches applicatives (non representees) et les couches inferieures. CCi et 
CC2. La fonction principale d§volue a cette couche 16 est une fonction de 
multiplexage/d^multiplexage. 

Les communications avec la carte a puce 2a s'effectuent selon un 

30 paradigme similaire k celui .utilis§ pour la manipulation de fichiers dans un 
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systfeme d'exploitation du type "UNIX" (marque depos6e) : OUVRIR 
("OPEN"), LIRE ("READ"), ECRIRE ("WRITE"), FERMER ("CLOSE"), etc. 

Du cote de la carte a puce 2a, on retrouve une organisation 
simitaire, a savoir la presence de deux couches basses, referencees CCai 
5 (couche physique) et CCaz (couche de lien de donnees), ainsi qu'une 
couche d'Interface 26a, tout a fait similaire a la couche 16. 

Selon une premiere caracteristique de I'invention, on prevoit, de part 
et d'autre, c'est-a-dire dans le terminal 1 et dans la carte a puce 2a, deux 
couches de protocoles spdcifiques : 13 et 23a, respectivement. 
10 . Dans le terminal 1, la couche specif ique 13 s'interface aux "drivers 

couches basses" 15, aux bibliotheques 14 des couches reseau, C3 et C4, et 
aux couches protocolaires du lecteur de carte 3, c'est-a-dire les couches 
inferieures, CCi et CC2, via la couche de multiplexage 16. La couche 
specif ique 13 permet le transfert de paquets reseaux de et vers la carte a 
15 puce 2a. En outre, elle adapte les applications existantes telles le navigateur 
Internet 10, le courrier electronique, etc.. pour des utilisations mettant en 
oeuvre la carte d puce 2a. 

Du cote de la carte a puce 2a, on retrouve une organisation tout a 
fait similaire constitute par une instance supplementaire de la couche 
20 specifique, referencee 23a, pendant de la couche 13. 

De fagon plus precise, les couches sp§cifiques, 13 et 23a, sent 
subdivisees en trois elements logiciels principaux : 

un module, 130 ou 230a, de transfert de blocs d'informations 
entre les couches 13 et 23a, via les couches conventionnelles CCi, CC2. 
25 CCai et CCa2 : 

une ou plusieurs pieces de logiciel, dites "agents intelligents", 
132 ou 232a. qui realisenl, par exemple, des fonctions de conversion de 
protocoles ; 
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et un module de gestion de la configuration specif ique, 131 et 
231a, respectivement ; module qui peut etre assimile a un agent intelligent 
particulier. 

Pour simplifier, on appellera ci-apres les agents intelligents. 
5 "agents", comme il a ete precedemment indique. 

On retrouve done, dans le terminal 1 et la carte a puce 2a, une pile 
protocolaire de communication entre les deux entites. 

Les couches de niveau deux (couches de lien de donnees), CC2 et 
CCa2, assurent I'^change entre la carte a puce 2a et le terminal 1. Ces 
10 couches sont responsables de la detection et I'eventuelie correction 
d'erreurs de transmission. Differents protocoles sont utilisables, et a titre 
d'exemples non exhaustifs les suivants : 

la recommandation ETSI GSM 11.11 ; 

le protocole d6fini par la nomne ISO 7816-3, en mode caractere 

15 T=0 ; 

le protocole defini par la nomie ISO 7816-3, en mode bloc T=1 

ou le protocole defini par la norme ISO 3309, en mode trame 
"HDLC" (pour "High-Level Data Link Control procedure" ou procedure de 
20 commande de liaison a haul niveau). 

Dans le cadre de {'invention, on utilisera de preference le protocole 
ISO 7816-3, en mode bloc. 

De fagon connue en sol, d chaque couche de protocole, il est 
associ§ un certain nombre de primitives qui permettent les ^changes de 
25 donn§es entre couches de meme niveau et d'une couche a I'autre. A titre 
d'exemple, les primitives associ6es d la couche de niveau deux sont du type 
"demande de donn6es" {"Data.requesf) et "envoi de donnees" par la carte 
{"Data.response"), ainsi que "confirmation de donnees" {"Data.confirm"), etc. 
De fagon plus specif ique, les couches 13 el 23a sont charg§es du 
30 dialogue entre la carte a puce 2a et I'hote, c'est-a-dire le terminal 1 . Ces 
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couches permettent lechange d'informations entre un utilisateur (non 
reprdsente) du terminal 1 et la carte a puce 2a, par exemple via des menus 
deroulants sous la forme d'hypertexte au format "HTML". Elles permettent 
aussi la mise en place d'une configuration adaptee pour I'emission et/ou la 
5 reception de paquets de donnees. 

Comme il a 6te indique ci-dessus, les couches comprennent trois 
entites distinctes. 

La premiere couche, 130 ou 230a, est essentiellement constitute 
par un multiplexeur logiciel. Elle pemiet rtchange d'informations entre la 
10 carte a puce 2a et le terminal hote 1 , sous la fonne d'unites de donn§es de 
protocole. Elle joue un role similaire a celui d'un commutateur de paquets de 
donnees. Ces unites sont emises ou regues via la couche de niveau deux 
(couche de liens de donn§es). Ce protocole particulier de communication 
permet de mettre en communications au moins une paire d* "agents". Le 
15 premier agent de chaque paire, 132, est situe dans la couche 13, cote 
terminal 1, le second, 232a, est situe dans la couche 23a, cote carte a puce 
2a. Une liaison entre deux "agents" est associ§e a une session, que Yon 
pourra appeler "S-Agenf\ Une session est un echange de donn6es 
bidirectionnel entre ces deux agents. Si Tune ou Tautre des couches, 13 et 
20 23a, comporte plusleurs agents, les agents d'une meme couche peuvent 
aussi etablir de sessions entre eux et/ou avec les modules 131 et 231a, qui 
constituent des agents particuliers. 

De fagon plus precise, un agent est une entite logicielle autonome 
qui peut realiser tout ou partie de fonctions des couches de niveau trois et 
25 quatre. en fonction de la configuration mise en oeuvre par le terminal 1 . 

Les agents sont associes a des propri6t6s ou attributs particuliers. 
Pour fixer les id§es, et a titre d'exemple non limitatif, les six propri6t6s 
suivantes sont associees aux agents : 

"hote" : agent localise dans le terminal ; 
30 - "carte" : agent localis6 dans la carte a puce ; 

"locar : agent ne communiquant pas avec le reseau ; 
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"reseau" : agent communiquant avec le reseau (c6t6 terminal) ; 
"client" : agent qui initialise une session ; 
"serveur" : agent qui regoit une demande de session. 
Un agent particulier est identifie par une reference, par exemple un 
5 nombre entier de 16 bits (c'est-a-dire compris entre 0 et 65535). Le bit de 
poids fort (b15 = 1) indlque si la ref6rence est locale (communications 
locales a la carte d puce ou au terminal) ou distante (b15 = 0). 

II existe deux grandes categories d'agents : les agents de type 
"serveur", qui sont identififes par une reference fixe, et les agents de type 
10 "client", qui sont identifies par une reference variable, que Ton peut qualifier 
d'ephemere, delivree par le module de gestion de configuration, 131 ou 
231a. 

Les agents communiquent entre eux a I'aide d'entite dites "unites de 
donnee de protocole" ou "pc/u" (pour "protocol data unit", selon la 
15 terminologie anglo-saxonne) constituant une reference de destination et une 
reference de source. On pourrait egalement appeler cette "pofu" particuliere 
"SmartTP pdu'\ en reference au terme anglais "Smart Card" (carte a puce) 
couramment utilise. Les "pdw" utilisent notamment les references d^finies ci- 
dessus. 

20 Une "SmartTP pdu'\ ou plus simplement "pdu" ci-apres. comporte 

une r6f§rence source, une reference de destination, un ensemble de bits 
constituant des drapeaux ou "flags" qui precisent la nature de la "pc/a", et 
des donnees optionnelles : 

- le drapeau ''OPEN*' (ouvert) est positionne pour indiquer Touverture 
25 d'une session ; 

- le drapeau ''CLOSE** (ferme) indique la fermeture d'une session ; et 

- Le drapeau "BLOCK" (verrouille) indique que Tagent est en attente d'une 
r§ponse de son correspondant et suspend toute activity. 

On appellera jeton une "pc/u" qui ne comporte pas de donndes. 
30 Uentite "SmartTP" controle Texistence de Tagent destinataire et 

realise la commutation d'un paquet vers ce dernier. 
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Une session agent "^S-Agenr possdde trois etats remarquables, d 

savoir ; 

- un etat deconnecte : aucune session n'est ouverte avec un autre agent 

- un etat connecte : une session est ouverte avec un autre agent, une 
5 session '"S-Agenr etant identifiee par une paire de references ; et 

- un etat bioqu6, Tagent etant connecte et attendant une r6ponse de son 
correspondant. 

Le mecanlsme d*etabllssement d'une session "^S-Agent" est le 

suivant : 

10 - une nouvelle instance d'un agent client est cr§§e (cote carte a puce ou 
terminal), cet agent etant identifie par une reference ephemere pseudo- 
unique ; 

- Tagent client emet une "pdu" a destination d*un agent serveur (dont la 
reference est connue par ailleurs) avec le drapeau "OPEAT positionne et 

15 I'agent client passe a I'etat connecte ou bloque selon la valeur du drapeau 
""BLOCfC ; et 

- I'agent serveur regoit la "pc/u" avec le drapeau ''OPEN*' et passe a Tetat 
connecte 

Une fois une session ouverte, deux agents echangent des donnees 
20 via des "pcft/". 

Le mecanlsme de fermeture d'une session est le suivant : 

- un agent emet une "pcfa" avec le drapeau "CLOSE" positionne (et 
qui comporte 6ventuellement des donnees ; et 

- I'autre agent regoit une "pcfu" avec le drapeau "CLOSE* positionne 
25 (et qui comporte eventuellement des donnees) et la session "S-Agenr passe 

k r^tat d6connect6. 

La figure 3 illustre de fagon sch^matique le diagramme d'dtats des 
sessions "'S-Agent, telles qu'elles viennent d'etre rappel^es. 

Les couches 130 et 230a gerent des tables (non representees) qui 
30 contiennent la liste des agents presents, cdt6 terminal bote 1 et carte k 
puce 2a. 
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De tagon pratique, les agents permettent d'echanger des donnees 
(de Thypertexte, par exemple), mais egalement de declencher des 
transactions reseau, autorisant des communications entre la carte a puce 2a 
et un serveur eloigne 4 (figure 2). 
5 Les modules de gestion de configuration, 131 et231a, 

respectivement, sont assimilables a des agents particuliers. Par exemple, le 
module 131 . cote terminal hote 1 , gere notamment des informations relatives 
k la configuration de ce terminal (modes de fonctionnement), liste des autres 
agents presents, etc. Le module 231a, c6t§ carte a puce 2a, a des fonctions 

10 analogues. Ces deux agents peuvent etre mis en communication I'un avec 
I'autre pour etablir une session. 

De fagon pratique, la carte a puce 2a est avantageusement 
"adress§e" par utilisation d'une adresse "URL" (pour "Universal Resource 
Locator") definissant un rebouclage sur le terminal 1 lui-meme. et non un 

15 pointage sur un serveur externe. A titre d'exemple, la structure de cette 
"URL" est habituellement la suivante : 

http://1 27.0.0. 1:8080 (1), 
dans laquelle 127.0.0.1 est I'adresse "IP" de rebouclage etSOBO est le 
numero de port. 

20 La figure 4 illustre de fagon simplifiee I'architecture logique d'un 

systeme selon invention du type represents sur la figure 2, mais represents 
de fagon plus detaillee. La carte a puce 2a comprend plusieurs agents, dont 
deux seulement ont ete reprSsentes : un agent de type non precis6ment 
d6fini 232ai et un agent 232a2. de type dit "WEB". La pile logique 

25 comprend, les couches de protocole infSrieures, rSferencees 200a, 
r6pondant aux nonmes ISO 7816-3 (figure 2 : CCai et CCa2). le gestionnaire 
de commandes "APDU" 201ai, et le multiplexeur de paquets230a. ce 
dernier etant interface aux agents, notamment I'agent "WEB" 231a2. 

Du cote terminal, il existe deux piles, I'une communiquant avec le 

30 rSseau Internet f?/, I'autre avec la carte a puce 2a. La premiere pile 
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comprend les organes 1 1 (figure 2 : Ci et C2) d'acces au reseau (normes 
OSI 1 et 2) et les couches de protocole TCP/IP" (figure 2 : C3 et C4), 
referencees 100. Ces dernieres couches sont interfacees avec le navigateur 
"WEB*' 10. L'autre pile comprend les couches de protocole inferieures. 
5 referencees 101 , repondant aux normes ISO 7816-3 (figure 2 : Ci et C2). 
gestionnaire 102 d'ordres "APDU" et le multiplexeur de paquets 130, ce 
dernier etant interface avec des agents, dont un seul 132, est represente. Ce 
dernier, que Ton supposera de "type reseau", peut en outre communiquer, 
d'une part avec le navigateur 10, via les couches TCP/IP" 101, d'autre part 

10 avec le reseau Internet /?/, via ces memos couches 'TCP/IP" 101 et Torgane 
1 1 , d'acces au reseau Rl. 

Le gestionnaire d'ordres "APDU" 201a est egalement interface avec 
une ou plusieurs couches de niveau applications, que Ton appellera 
simplement applications. Ces applications, >4,, ^j, sont, comme 11 a 

15 et§ indique, des applications de type conventionnel. 

En resum§, la fonction client/serveur "WEB", fournie par la carte a 
puce 2a, peut etre r§alisee par Tassociation de I'agent "WEB" 232ai dans la 
carte a puce et de I'agent reseau 132 dans le terminal 1 , et par la mise en 
oeuvre de sessions entre agents, comme il a ete decrit. 

20 La carte a puce 2a presente done bien la fonctionnalit^ 

client/serveur "WEB". En outre, selon une caracteristique du precede de 
I'invention, n'importe quelle application conventionnelle, /*i k An^ du type 
"CGA" pr6cit6, peut §tre activ6e au travers de ce client/serveur "WEB", soit 
par le navigateur "WEB" 10 present dans le terminal 1 , soit par un navigateur 

25 eloigne 4, localise en un point queiconque du reseau Internet Rl, par la mise 
en oeuvre de sessions entre agents. Selon le proc6d§ de Tinvention, les 
applications, aAp, ne necessitent pas d'etre r§-§crltes et sont mises en 
oeuvre telles quelles. 

Dans le cadre de invention, tout ou partie des applications A^i aAn 

30 peut etre constituee par des "applets", charg6es initialement dans une 
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memoire non volatile de la carte a puce 2 ou, au contraire, chargees par 
rintermediaire des deux programmes de chargement OL et IL, dont on 
precisera ci-apres la nature et les lieux de stockage possible. 

Selon un autre aspect de I'invention. la fonction serveur "WEB" 
5 offerte par la carte a puce inclut un mecanisme similaire a la fonction dite 
"CGI" (pour "Common Gateway Interface" ou "interface de passerelle") 
implant§e dans les serveurs "WEB" classique. 

Avant de decrire un exemple d'architecture conforme a Tinvention. 
permettant de realiser une fonction de ce type, au sein meme de la carte k 
10 puce, il est utile de rappeler les principales caracteristiques d'un mode de 
fonctionnement "CGI". 

Le "CGI" est une specification de mise en oeuvre, depuis un serveur 
"WEB", d'applications ecrites pour les systemes d 'exploitation "UNIX" 
(marque deposee), "DOS", ou "WINDOWS" (marque deposee). A titre 
15 d'exemple, pour le systeme d'exploitation "UNIX", la specification est 
"CG1 1.1" et pour le systeme d'exploitation "WINDOWS 95", la specification 
est "CG1 1.3". 

Toujours a titre d'exemple. une requete "HTTP" pour une adresse 
"URL", du type : 

20 "http://www.host.com/cgi-bin/xxx.cgi" (2), 

dans laquelle "host" se refere a un systeme hote (generalement eloigne), 
est interpretee par un serveur "WEB" comme I'execution d'un script de 
commando, de type "CGI" nomme "xxx" et present dans le repertoire "cgi- 
bin" de ce systeme hote. Bien que le nom du repertoire puisse etre a priori 

25 quelconque, par convention, c'est le nom donne au repertoire stockant les 
scripts de type "CGI". Un script est une suite d'instructions du systeme 
d'exploitation du systeme hote dont le resultat final est transmis au 
navigateur "WEB" emetteur de la requete precitee. Differents langages 
peuvent etre utilises pour ecrire ce script, par exemple le langage "PERL" 

30 (marque deposee). 
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De fagon pratique, la requete est habituellement affichee sur un 
ecran informatique sous la forme tfun formulaire compris dans une page 
"HTLM". Le langage "HTLM" permet de traduire un formulaire en une 
adresse "URL". Le formulaire comporte un ou plusieurs champs, obligatoires 
5 ou non, qui sont remplis par un utilisateur a Taide des moyens de saisie 
habituels : clavier pour le texte. souris pour les cases a cocher ou les 
boutons dits "radio", etc. Le contenu du formulaire (ainsi qu'§ventuellement 
des informations et instructions dites "cachees") est emis a destination du 
serveur "WEB". Le code "HTLM" de la page decrit la structure materielle du 
10 formulaire (cadre, graphisme, couleur, et tout autre attribut), ainsi que la 
stmcture des champs de donnees a saisir (nom. longueur, type de donn§es. 
etc.). 

La transmission peut s'effectuer selon deux types de formats 
principaux. Un premier format utilise la m6thode dite "POST" et un second la 
15 methode dite "GET". Une information de type de format est presente dans le 
code de la page formulaire. 

Ce mecanisme n*est cependant pas directement transposable a une 
carte a puce, meme si celle-ci offre la fonctionnalite client/serveur "WEB" 
conform6ment a Tune des caracteristiques de I'invention. 
20 On va maintenant decrire un exemple d'architecture permettant 

d'activer une application quelconque, de type conventionnel, via un serveur 
"WEB" sur la carte a puce, par reference a la figure 5. 

Parmi les agents intelligents, conforme a I'un des aspects de 
rinvention, on prevoit des agents intelligents particuliers, que Ton appellera 
25 ci-apres "Agents traducteurs de script" ou de fagon abregee "ATS". Le script 
est alors interprete par un des agents intelligents. Cette traduction peut etre 
realisee de differentes manieres : 

a/ par I'agent "WEB" 232ai lui-m§me, qui est dot§ dans ce cas d'une 
double capacity ; 
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b/ par un agent script unique capable de traduire I'ensemble des scripts 
presents dans la carte a puce 2a ; 

d par un agent de script dedi6 que Ton appellera "ATSD" ci-apres (un 
agent par script) ; ou 
5 61 par un agent "APDU- 2010a du gestionnaire d'ordres "APDU- 201a. 
qui est dot§, dans ce cas, d'une double capacity. 

Uagent "APDU" 2010a est une composante de la couche 
gestionnaire d'ordres "APDU" 201a. Cette derniere est une couche capable 
de centrallser tous les ordres "APDU" emis et/ou regus par le systeme, de 
10 selectionner des applications, parmi a A^, nnais egalement d'offrir une 
interface de type agent intelligent. Elle est done capable, selon rune des 
caracteristiques de invention de communiquer avec tous les agents 
intelligents (via des sessions), que ces agents soient localises dans 
i'enceinte 6 ou la carte a puce 2a. 
^5 Dans le cas c/ ci-dessus. une session est ouverte entre I'agent 

"WEB" 232ai et Tun des agents "ATSD". 

La figure 5 illustre un exemple d'architecture pour laquelle les 
agents traducteurs sont du type "ATSD". lis sort references ATSy a ATS„ et 
associes aux applications A^ a A^. L'application selectionnee etant supposee 
20 etre I'application A, la session s'etablit entre I'agent "WEB" 232ai et Tagent 
ATS.. 

Un agent traducteur de script g§nere une suite d'ordres "APDU". 
Une session est ouverte entre I'agent traducteur. par exemple I'agent ATS., 
et regent "APDU" 2101a. Les ordres sont alors emis vers I'agent 
25 "APDU" 2101a. Le gestionnaire d'ordres "APDU" 210a selectionne 
I'application "CGA" et lui transmet les ordres "APDU", ordres traduits et 
done conventlonnels, qu'elle est en mesure de comprendre. Cette 
application est done eorreetement activ6e, sans avoir d la modifier ou k la 
rS^crire. 
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Les reponses de Tapplication A, sont transmises au gestionnaire 
d'ordres "APDU" 210a, a Tagent "APDU" 2010a, puis de nouveau a Tagent 
ATSf (et de fagon plus generale a I'agent traducteur de script). 

Les differents cheminements sont representes symboliquement sur 
5 la figure 5 par des traits pletns reliant les blocs fonctionnels, ou en pointilles 
a rinterieur de ces blocs. 

Le proc^de selon rinventlon utilise les deux caracteristiques qui 
viennent d'etre rappelees : fonctionnement de la carte a puce en tant que 
serveur/client ''WEB", induant une fonction "cgi". Le chargement d'une 
10 "applet** dans la carte a puce s'effectue en etfet via I'interface "CGI" offerte 
par celle-ci. 

De fagon plus precise, selon une caracteristique de rinventlon, la 
partie de programme de chargement IL, localisee dans la carte a puce 2a, 
est constitute par un script. II s'agit, par exemple, d'un script assoctt a 

15 rapplication referencee A. sur la figure 5. Ce script est, selon une 
caracttristique du procfede de Tinvention, active par une requete "HTTP-, les 
echanges entre la partie OL et la partie IL s'effectuant selon le protocole de 
communication "TCP/IP". Les programmes IL et OL deviennent de ce fait a 
priori compatibles. En outre, 11 n'est plus necessaire que la proximity 

20 physique soit respectee, comme dans I'art connu (voir figure 1). La partie OL 
peut desormais etre localisee dans le terminal ou, de preference, dans un 
serveur §loign§ (les liaisons entre le serveur et le terminal s'effectuant 
suivant le protocole "TCP/IP"), voire, comme il le sera montre. etre stock6e 
dans la carte k puce elle-m§me. La requete "HTTP" precitee est initiee par la 

25 partie OL. 

II convient de remarquer que les donntes adressees k Tagent 
"WEB" 232ai sont transportees. de fagon conventionnelle en soi, sous 
formes d'ordres "APDU" destines a I'application particuliere constituee par le 
"Multiplexeur de paquets" 230a. Le gestionnaire d'ordres "APDU" 201a 
30 selectionne cette application de maniere tout a fait similaire aux autres 
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applications de type "CGA", a An, pr§sentes dans la carte a puce 2a. En 
d'autres termes, le multiplexeur de paquets 230a est vu par le gestionnaire 
d'ordres "APDU" 201a comme una application "CGA" ordinaire. 

La requete "HTTP" est analysee par Tagent "WEB" 232ai qui 
5 detecte une reference a un repertoire particulier, que Ton appellera ci-apres 
par convention "cgi-smart" (par analogic a "cgi-bin"), d'une part, et a une 
application particulldre, IL dans le cas de Texemple decrit. Le chemin 
complet est done, en I'occurrence "cgi-smart/il". 

Selon une caracteristique du precede de Tinvention, Tentite "11" ci- 
10 dessus designe un script particulier associe une application egalement 
particuliere (IL en Toccurrence). 

Une session est ouverte entre I'agent traducteur, par exemple 
I'agent ATSu et I'agent "APDU" 2010a. L'agent traducteur de script ATS\ 
genere une suite d'prdres "APDU". Les ordres sont emis vers Tagent 
15 "APDU" 2010a. Le gestionnaire d'ordres "APDU" 201a selectionne 
{'application "CGA" .4/ (par exemple rapplication IL) et lui transmet les ordres 
"APDU", ordres traduits et done conventionnels, qu'elle est en mesure de 
comprendre. Cette application est done correctement aetivee. 

La reponse de Tapplication IL {Aj) est transmise en sens inverse au 
20 gestionnaire d'ordres "APDU" 201a, a I'agent "APDU" 2010a, puis de 
nouveau a I'agent ATSj (et de fagon plus generate a I'agent traducteur de 
script). 

La reponse, constituee par un formulaire en langage "HTLM" 
reprend le chemin inverse, par la mise en oeuvre de sessions entre agents 
25 Intelligents apparies, pour etre re-transmise au terminal 1 et, eventuellement 
a un serveur eloigne 4 (figure 4), via le reseau Internet ft/, pour atteindre 
finalement I'application OL. 

La figure 6 illustre sch§matiquement I'architeeture logique 
permettant le chargement d'une "applet" selon le precede de {'invention. On 
30 retrouve sur ce schema les blocs materiels constitues par {e termina{ 1 , le 
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lecteur de carte a puce 3 et la carte d puce 2a, communiquant par mise en 
ceuvre du protocole normalise ISO 7816 precite et Techange d'ordres 
"APDU", de maniere classique en soi. La partie OL est mise en relation avec 
la partie IL (sous forme d'un script reference ILs), par des echanges selon le 
5 protocole Internet 'TCP/IP", de la maniere decrite precedemment, par mise 
en oeuvre des fonctions serveur "HTTP" (reference SC) et "CGI" de la carte a 
puce 2a. 

On doit bien comprendre que, bien que representes k Texterieur de 
la carte a puce 2a pour des raisons de commodite. les blocs SC et ILs sont 
10 constitues par differents modules internes de celle-ci, qui ont 6te d§crits par 
r6ference a la figure 5. 

Par centre, le programme OL n'est pas obligatoirement stock6 dans 
le terminal 1 . 

On va maintenant detainer un premier exemple de chargement 
15 d'une "applet" dans une carle a puce 2a, par mise en oeuvre de la methode 
dite "GET". 

On suppose que le fichier de chargement de T "applet", referencfe 7, 
presente la structure lllustree par la figure 7 : une entete 70, un corps 
principal 71 constitue par du "Byte Code" en langage "JAVA" et une 
20 signature electronique 72. L'entete represente un identifiant d'une application 
particulidre, g§n§ralement appele "Application Identifier" ou simplement 
"AID". La signature electronique 72 est un mot chiffre avec une cle publique 
ou privee, obtenu a partir du code 71. Uensemble du fichier 7 peut 
6galement etre chiffre, pour des raisons de confidentialite, lorsqu'il s'agit 
25 d'applications dites sensibles. Optionnellement, on peut prevoir une ou 
plusieurs signature(s) electronique(s) suppl6mentaire(s) non repr6sent6e(s). 

Les principales etapes du processus sont illustrees 
schematiquement par la figure 8. 

Pendant une premidre 6tape, la partie de programme de 
30 chargement OL recupere, par une commando de type "GET", un formulaire 
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de chargement a partir de la carte k puce 2a, formulaire en langage "HTML" 
que Ton appellera arbitrairement "download.htmr. 

Cette recuperation est effectuee en consultant une page 
correspondante dont rURL est typiquement de la forme suivante : 
5 http://1 27.0.0.1 :8080/download.html (3), 

dans laquelle http://1 27.0.0. 1:8080 est I'adresse URL de rebouclage 
proprement dite, telle qu'elle a ete d^finie par la relation (1), et 
"download.html" la page "HTML" a obtenir. Cette requete met en oeuvre une 
session entre agents intelligents comme II a ete decrit en regard des figures 

10 2 a 4, selon un premier aspect de ('invention. La carte a puce 2a joue alors le 
role d'un serveur "WEB". 

La carte a puce 2a envoie le formulaire "download.htmr lors d'une 
deuxieme etape, toujours par ouvertures de sessions entre agents 
intelligents apparies, selon le precede de I'invention. Le formulaire obtenu 

15 peut etre affiche sur un ecran 5 par Tintermediaire du navigateur 10. 

Pour fixer les iddes, un exemple d'un tel formulaire 8 est iliustre par 
la figure 9. Outre diverses zones graphiques et de textes 80 (titre, etc.), le 
formulaire comprend des zones d'affichage pour Tentete 70 du fichier de 
chargement 7, le "Byte Code" 71 et la signature 72. La zone d'affichage 71 

20 est du type dit "TEXTAREA" en langage "HTML" et presente une facilite dite 
d' "ascenseur" pour I'affichage deroulant de textes longs. Les informations 
correspondantes, telles qu'elles apparaissent sur la figure 9, sont purement 
arbitraires. Enfin, on prevoit, de fagon classique en soi, un bouton d'envoi 
"send", reference 81 , et un bouton de remise a zero "reset", reference 82. 

25 Ces boutons sont a la disposition d'un utilisateur du terminal (non 
represente). Le bouton d'envoi 81 permet de valider le formulaire et le 
retransmet ^ la carte a puce 2a ("soumettre le fichier de chargement" sur la 
figure 8) et le bouton de remise a zero 82 permet d'effacer les informations 
affichees et de r^-initialiser le formulaire. 

30 Le code "HTML" necessaire pour programmer un tel formulaire est 

bien connu en soi et est a la portee de I'homme de m6tier. II n'est pas 
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necessaire de le detaillcK de nouveau. On peut cependant indiquer qu*il 
contient notamment une ligne de code en langage "HTML" qui se presente 
typiquement sous la forme : 

<form action="http://1 27.0.01 :8080/cgi-smart/loader"> (4), 
5 dans laquelle http://1 27.0.01:8080 est TURL de rebouclage de la relation (1), 
cgi-smart le repertoire "CGI" precite contenant le script de chargement 
"loader" que Ton a appele "il", script associe a la partie IL du programme de 
chargement. 

Si Taffichage visuel du formulaire 8 sur Tecran 5 n*est pas souhait6 
10 (par exemple s*il nV a pas d'op^rateur humain, les informations peuvent etre 
cachees incorporant le parametre "HTML" suivant : •TYPE=hidden" dans la 
ligne de code (4) precitee. 

Lors d'une troisieme etape, la partie OL envoie une requete "HTTP" 
de type "GET" a la carte a puce 2a, toujours par ouverture de sessions entre 
15 des agents intelligents apparies. En falsant appel a la fonction "CGI" offerte 
par la carte a puce 2a, telle qu'elle a ete decrite en regard de la figure 5, 
rapplication IL s'execute, le serveur "WEB" form§ par la carte a puce 2a 
passant les parametres de la requete "HTTP" a cette. derniere application. 

La requete precitee contient une ligne de code typiquement de la 
20 forme suivante : 

Smart/loader?AID=xxx&ByteCode=yyy&Signature=zz2 (5), 
Dans laquelle "xxx" est Tentete 70 ("2001" dans Texemple de la 
figure 9), "yyy" est le "Byte Code" 71 ("0123456789ABCDEF" dans Texemple 
de la figure 9) et "zzz" la signature 6lectronique 71 ("0123456789ABCDEF" 
25 dans I'exemple de la figure 9). Les trois parties du fichier de chargement sont 
done bien inserees dans trois champs du formulaire "HTML" 8, sous forme 
concaten§e. 

Le chargement d'une "applet" particuliere identifi6e par Tentete 70 a 
lieu d ce moment. 

30 Enfin, lors d'une quatrieme etape un code de retour est transmis de 

la partie IL a la partie OL, toujours par mise en oeuvre de sessions entre 
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agents appari6s. II s'agit en g6n6ral d'un simple acquittement ou, si 
reparation ne s'est pas reallsee correctement d'un code d'erreur. Dans ce 
dernier cas, il est necessaire de renouveler les etapes 1 ^ 4. 

Comme solution alternative, il est possible d*utiliser la methode 
5 "POST" precitee. Pour fixer les idees. la figure 10 illustre un exemple d'un tel 
formulaire reference 8'. On retrouve diverses zones de texte et de graphique 
80, une zone d'affichage de Tentete 70 et une zone d'affichage de la 
signature 6lectronique 72, ainsi que des boutons d'envoi "send" 81 et de 
remise a zero "Reset" 82. Ces elements jouent un role tout a fait similaire 

10 aux elements de memos reference de la figure 9 et il est inutile de les re- 
decrire. Par centre, la zone d'affichage 71 ' ne visualise plus explicitement le 
"Byte Code", mais un repertoire ou un sous-repertoire ou le code de r 
"applet" a charger est enregistre. En I'occurrence, cette zone pointe sur un 
fichier, appele arbitrairement "APPLET.BIN", enregistre sur une unite de 

15 stockage appelee "C", qui peut etre un disque dur present dans le terminal 1 . 
Un bouton supplementaire de navigation "browse" 83 permet de balayer les 
divers (sous-)repertoires de ce disque et de selectionner un fichier particuiier 
("APPLET.BIN"). 

La methode "POST" comme la methode "GET" est bien connue en 
20 soi, et il est inutile de la re-decrire en detail. Dans le cadre precis de 
invention, r "applet" correspondant au fichier "APPLET.BIN" est chargee, a 
partir de Tunite "C", de maniere similaire a ce qui a ete decrit pour la 
methode "GET". 

On va maintenant decrire un deuxieme exemple de chargement 
25 d* "applet" dans la carte a puce 2a, 

II est egalement possible d'enchainer plusieurs formulaires lors du 
chargement. A la place d'un simple statut (acquittement ou code d'erreur 
dans le premier exemple decrite en regard de la figure 8), le retour de la 
partie IL contient alors un nouveau formulaire. Ainsi, des sequences 
30 dynamiques d'echanges entre les parties OL et IL peuvent etre r6alis6es. 
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Par exemple, apres analyse du fichier de chargement, la partie IL 
peut demander une autorisation (c*est-a-dire une signature electronique) 
supplementaire, par exemple celle d'une instance gouvernementale. Ella 
renvoie alors a la OL un formulaire qui peut avoir typiquement la structure 
5 "HTML" suivante (6) : 



10 



<TITLE>Authorisation form </TITLE> 

<FORM ACTION="http://@carte:8080/cgi-smart/loader"> 

<INPUT TYPE="text" NAME="GouvSignature" MAXLENGTH="8">Signature 

</FORM> 



dans laquelle "Authorisation form", entre les balises "HTLM" ddnommees 
"<TITLE>" et </TITLE>, repr6sente le titre (arbitraire) du formulaire, "(3)carte" 
la traduction litterale de Tadresse URL de rebouclage de la relation (1) et 
15 8080 le numero de port, la ligne de code : 

<INPUT TYPE="text" NAME="GouvSignature" MAXLENTH="8">Signature 
(7) 

requiert I'entree tfune variable appelee arbitrairement "Signature", en mode 

texte, de longueur maximale 8 octets, et </FORM> est la balise "HTML" 
20 indiquant la fin du code de formulaire. 

Le processus complet comprend alors deux etapes supplementalres 

avant Tetape finale d'acquittement ou de code d'erreur, soit six etapes, 

comme illustre par la figure 1 1 . 

De fagon plus generate, le nombre d'allers et retours peut d6pendre 
25 de parametres figurant dans Tun ou Tautre des formulaires echanges entre la 

carte a puce et la partie OL des programmes de chargement. 

Jusqu'a ce point, la localisation de la partie OL n'a pas ete precisee 

express6ment. Outre le fait que le precede rend, a priori, compatible OL et 

IL, 11 pemnet aussi une trds grande souplesse pr6cis6ment quant a cette 
30 localisation, 6tant entendu que la partie IL est stockee dans la carte a puce 

2a comme formant Tune des applications pr^sente dans cette carte a puce. 

Le proced6 selon Tinvention presente notamment Tavantage suppl6mentalre 
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de ne plus exiger une proximit6 physique entre les deux parties OL et IL, 
puisqu'elles ne sont plus tributaires du protocole de communication ISO 
7816. les echanges entre ces deux portions de logiciel mettant en oeuvre le 
protocole de communication Internet TCP/IP. 
5 Aussi, la partie OL, ainsi que les donnees proprement dites de 

r "applet" a charger sur la carte a puce 2a peuvent etre stock6es soit en 
local, soit dans un site §loign§. Dans tous les cas cependant. les echanges 
entre ces deux parties mettent en oeuvre, comme il vient d'etre rappel6, un 
protocole de communication "TCP/IP" et le chargement d'une "applet" se 
10 deroule comme 11 a 6te rappele precedemment grace aux fonctions de 
serveur/client "WEB" et "CGI" offertes par la carte a puce 2a. 

On va decrire maintenant. par reference aux figures 12A a 12G, les 
principales architectures pouvant etre mises en oeuvre dans le cadre de 
I'invention. 

15 La figure 12 A illustre une architecture de systeme selon laquelle la 

partie OL est stockee en local sur le terminal 1 . Celui-ci est connecte a un 
serveur eloigne 4, via le reseau Internet Rl, Les donnees de r "applet" a 
charger dans la carte a puce 2a, referencees Da, sont stock6es sur ce 
serveur 4. Une requete "HTTP" permet de les transferer vers la carte a puce 
2a, via le terminal 1 (et un lecteur de carte k puce non represente), par mise 
en oeuvre du protocole de communication Internet "TCP/IP". 

Dans rarchitecture de systeme representee sur la figure 12B, la 
partie de programme de chargement OL et les donnees Da sont stockees 
localement dans le terminal 1 . La connexion du terminal 1 au reseau Internet 
Rl est optionnelle. Pour le moins, elle n'est pas requise pour le chargement 
d'une "applet" selon les etapes du precede de Tinvention. Cette connexion a 
ete representee en traits pointings. Le terminal peut done etre autonome. 

Dans rarchitecture de systeme representee sur la figure 12C, la 
partie de programme de chargement OL et les donnees Da sont stockees 
dans un serveur distant 4. Les communications entre le serveur 4 et la carte 
a puce 2a, via le reseau Internet /?/, le terminal 1 et le lecteur de carte a 
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puce (non represente) 3'effectue par des requetes "HTTP", et mise en oeuvre 
du protocole TCP/IP". 

^architecture de systdme representee sur la figure 12D est similaire 
a celle de la figure 12C. La seule difference est que la partie de programnne 
5 de chargement OL est stockee dans un premier serveur distant, reference 
4a, et que les donn^es Da, sont stockees dans un second serveur distant, 
reference 4b. 

Dans Tarchitecture de la figure 12E, la partie du programme de 
chargement, referencee ici OU, est constituee par un composant du 
10 navigateur 10 iui-meme. II s*agit avantageusement d*une ''applet" int^gree 
dans ce navigateur. Le type d'entree ^ utiliser dans ce cas est "file" (fichier). 

De fagon avantageuse egalement, les donnees Da, de r "applet" a 
charger sur la carte a puce 2a, peuvent etre stockees sur un support 
d'enregistrement de donnees externe 9, par exemple une disquette comme 
15 illustre par la figure 12E. Naturellement d*autres supports sont utilisables : 
CedeROM, bande magnetique, etc. 

Si on utilise la methode "POST" precit§e, il suffit de specifier la lettre 
de I'unite dS stockage, par exemple "A" pour la disquette 9, un eventuel 
chemin (repertoire, sous-repertoires) et le nom du fichier ^ charger. Pour 
20 fixer les idees, le chemin complet pourrait etre typiquement : 

A:\APPLETBIN (8) 
Du fait de la fonction serveur/client "WEB" offerte par la carte a 
puce 2a, selon une des caracteristiques du precede de Tinvention, le 
navigateur 10 est a meme. contrairement a Tart connu, de communiquer 
25 directement avec cette derniere, comme il Ta §t6 montr6 en regard des 
figures 2 a 4. Les communications s*effectuent par Pouverture de sessions 
entre agents apparies. 

L'architecture de systeme illustree par la figure 12F est une variante 
de rarchitecture de la figure 12E. Selon cette variante, la partie de 
30 programme de chargement OL est stock§e dans la carte ^ puce 2a elle- 
meme, sous forme d'une "applet" en langage "JAVA". Par une requete 
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"HTTP", cette "applet" peut etre chargee dynamiquement sur le terminal 1 , 
en OL". Ce chargement s'effectue a I'aide de requetes posees par le 
navlgateur 10, lors d'etapes prdliminaires. Une fois la partie OL chargee, les 
etapes ulterieures sont communes au cas precedent. Les donnees Da 
5 peuvent egalement etre stockees sur un support externa, par exemple une 
disquette 8. 

L'architecture de systeme de ia figure 12G est une variante de celle 
de la figure 12F. La seule difference est que la partie de programme de 
chargement OL est stockee sur un sen/eur eloigne 4, sous forme d'une 
10 "applet" en langage "JAVA". Comme prec6demment, par une requete 
"HTTP", cette "applet" peut §tre chargee dynamiquement sur le terminal 1 , 
en OL". Ce chargement s'effectue a I'aide de requetes posees par le 
navigateur 10, lors d'etapes preliminaires. Les autres etapes sont communes 
au cas precedent. 

*5 " est Clair que d'autres variantes d'architecture peuvent §tre mises 

en OBuvre sans sortir du cadre de I'invention. II est notamment possible de 
charger les donnees Da dans le terminal 1 a partir de diverses sources : par 
exemple a partir d'un autre systeme informatique, connecte au terminal 1 par 
un r6seau local ou par tous autres moyens telematiques. 

20 A la lecture de ce qui precede, on constate aisement que I'invention 

atteint bien les buts qu'elle s'est fix6s. 

La mise en oeuvre du chargement d'une "applet" dans une carte a 
puce par I'interface "CGI" d'un serveur "WEB" log6 dans cette carte a puce 
pr^sente notamment les avantages suivants : 

?5 L'utilisation de formulaires en langage "HTML" standardise le 

chargement et rend les parties de programmes de chargement OL et IL a 
priori compatibles. En effet, comme 11 a §t§ montr§, c'est la partie IL situee 
dans la carte a puce qui d§crit, dans les champs du ou des formulaire(s) 
renvoye(s), le parametrage de chargement auquel 11 s'attend. 
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Par ailleurs, ce mdcanisme de communication entre les parties de 
programme de chargement OL et IL permet de gerer simplement des 
sequences d^echanges dynamiques lors du chargement. 

L'utilisation des protocoles Internet "HTTP" et "TCP/IP" pour les 
5 ^Changes entre les parties de programme de chargement OL et IL permet de 
les separer physiquement. Seul un routage de paquets "IP" est necessaire 
sur le terminal. Le chargement peut alors se faire dans un lecteur carte a 
puce banalise. puisque Ton conserve le protocole de communication ISO 
7816. Le terminal peut etre un simple micro-ordinateur standard connects k 
10 Internet. 

Selon un aspect avantageux egalement du precede de invention, 
les applications stockees dans la carte a puce restent standards, et done 
n'ont pas a etre re-ecrites. La carte a puce et le terminal eux-memes ne 
necessitent que peu de modifications pour pouvoir accommoder le precede 
15 de rinvention : ces dernieres se resument k Timplantation, dans ces deux 
unites, d'une couche logicielle de protocole de communication qui a 6t§ 
appel§e specifique, couche logicielle incluant des agents intelligents. 

Alternativement, la partie de programme de chargement OL peut 
etre chargee dynamiquement sur le terminal, au travers la carte, a partir de 
20 celle-ci ou rfun sen/eur "HTTP" 6loigne. 

Un simple navigateur Internet peut etre utilis§ comme programme 
de chargement OL. 

II doit etre clair cependant que rinvention n'est pas llmitee aux seuls 
exemples de realisations explicitement decrits, notamment en relation avec 
25 les figures 2 a 12G. 

□'autre part, en lieu et place du langage "HTML", d'autres langages 
similaires, adapt§s aux protocoles de communication de type "Internet" 
peuvent §tre utilises, notamment le langage "XML". 

^Invention concerne aussi un precede de chargement d'une piece 
30 de logiciel dans une carte a puce a partir d*un terminal connecte a ladite 
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carte a puce par Tintermediaire d'un lecteur de carte a puce permettant des 
communications selon un premier protocole d§termln§, le terminal et la carte 
a puce comprenant des moyens de traitement d'information et des moyens 
de stockage dinformation, ledit chargement s'effectuant par la mise en 
5 oeuvre et la cooperation de premier et second programmes de chargement, 
ledit second programme de chargement etant stocke dans les moyens de 
stockage d'information de ladite carte k puce, caract6ris§ en ce qu'il 
comprend au moins les phases suivantes : 

a/ une premiere phase preliminaire consistant a implanter, dans les 
10 moyens de stockage d'information de ladite carte a puce (2a), une 

premiere piece de logiciel (23a), formant une couche protocolaire de 
communication specifique ; 

b/ une deuxieme phase preliminaire consistant a implanter, dans les 
moyens de stockage d'information dudit terminal (1), une seconde 
15 piece de logiciel (13), formant une couche protocolaire de 

communication specifique ; 

en ce que lesdites premiere et seconde pieces de logiciel (13, 23a) 
comprennent en outre au moins une paire de premieres entites logicielles 
appariees (132, 232a), chacune desdites entites (132, 232a) cooperant I'une 

20 avec Tautre. grace auxdits moyens de traitement d'information du terminal et 
de la carte a puce, de maniere a permettre Tetablissement d'une session 
d'echanges de donnees bidirectionnels entre au moins ledit terminal (1) et 
ladite carte a puce (2a), de maniere a ce que ladite carte a puce (2a) offre la 
fonctionnalit6 d'un cllent/serveur "WEB" ; 

25 en ce qu'il comprend une troisieme phase preliminaire consistant ^ 

implanter dans les moyens de stockage d'information de ladite carte a puce 
(2a) au moins une deuxieme entite logicielle {ATS^ - ATS^), apte a interpr6ter 
une suite d'instructions et k la traduire en une suite d'ordres, de maniere a 
cooperer avec ladite seconde piece de logiciel specifique (23a) pour que 

30 ladite carte a puce offre une fonctionnalite d'interface passerelle dite "CGI", 
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la dite carte k puce conprenant au moins une desdites suites ^instructions 
associee au dit second programme de chargement (IL) ; 
et en ce qu'il comprend au moins les etapes suivantes : 

1/ ouverture d'une premiere session d'echanges de donn6es 
5 entre au moins ledit terminal (1) et ladite carte a puce (2a) grace 

auxdits moyens de traitement d'information du terminal et de la carte a 
puce, pour la transmission d'une requ§te pour que ledit premier 
programme de chargement (OL) recupere des donnees de 
parametrage de chargement fournies par ledit second programme de 
10 chargement (IL) ; 

2/ ouverture d*une deuxieme session d'echanges de donnees 
entre ladite carte A puce (2a) et au moins ledit terminal (1) grace 
auxdits moyens de traitement d'information du terminal et de la carte a 
puce, pour transmettre lesdites donnees de parametrage de 
15 chargement au dit premier programme de chargement (OL), lesdites 

donnees de parametrage comportant une reference aux dites 
instructions associees au dit second programme de chargement (IL) ; 
et 

3/ ouverture tfune troisieme session d'echanges de donnees 
20 entre au moins ledit terminal (1) et ladite carte a puce (2a) grSce 

auxdits moyens de traitement d'information du terminal et de la carte a 
puce, pour la soumission d'un fichier de chargement (7) prenant en 
compte lesdites donnees de parametrage de chargement, ledit fichier 
comprenant des donnees (70, 71, 72) associees a ladite piece de 
25 logiciel a charger (Da) ; interpretation de ladite suite d'instructions 

associee au dit second programme de chargement (IL), par mise en 
oeuvre de ladite fonctionnalite "CGI", de maniere a generer une suite 
d'ordres transmise au dit second programme de chargement (IL), ^ 
ex^cuter ce programme (IL) et ^ obtenir ledit ddchargement de ladite 
30 piece de logiciel (Da). 
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REVEND IC ATIONS 

1 . Proced6 de chargement d'une piece de logiciel dans une carte d puce ei 
partir d'un terminal connects d ladite carte k puce par I'intermddiaire d'un 
5 lecteur de carte a puce permettant des communications selon un premier 
protocole determine, ledit chargement s'effectuant par la mise en oeuvre 
et la cooperation de premier et second programmes de chargement, ledit 
second programme de chargement 6tant stocks dans ladite carte a puce, 
caract§ris§ en ce qu'il comprend au moins les phases suivantes : 

^0 al une premiere phase preliminaire consistant a implanter, dans 

ladite carte k puce (2a), une premiere piece de logiciel (23a), formant 
une couche protocolaire de communication specif ique ; 

b/ une deuxi^me phase pr6liminaire consistant a Implanter. dans 
ledit terminal (1), une seconde piece de logiciel (13), formant une 
15 couche protocolaire de communication specifique ; 

en ce que lesdites premiere et seconde pieces de logiciel (13, 23a) 
comprennent en outre au moins une paire de premieres entites logicielles 
appariees (132, 232a), chacune desdites entites (132, 232a) cooperant I'une 
avec I'autre de maniere a permettre I'etablissement d'une session 
20 d'echanges de donnees bidirectionnels entre au moins ledit terminal (1) et 
ladite carte k puce (2a), de maniere a ce que ladite carte a puce (2a) offre la 
fonctionnalite d'un client/serveur "WEB" ; 

en ce qu'il comprend une troisieme phase preliminaire consistant a 
Implanter dans ladite carte a puce (2a) au moins une deuxidme entity 
25 loglcielle (>47"S, - ATS^), apte a interpreter une suite d'instructions et a la 
traduire en une suite d'ordres, de maniere a coop6rer avec ladite seconde 
piece de logiciel specifique (23a) pour que ladite carte k puce offre une 
fonctionnalite d'interface passerelle dite "CGI", ia dite carte a puce 
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comprenant au moins une desdites suites d'instructions associee au dit 
second programme de chargement (IL) ; 

et en ce qu'il comprend au moins les etapes suivantes : 

1/ ouverture d'une premiere session tfechanges de donnees 
5 entre au moins ledit terminal (1) et ladite carte a puce (2a). pour la 

transmission d'une requete pour que ledit premier programme de 
chargement (OL) recupere des donnees de param6trage de 
chargement fournies par ledit second programme de chargement (IL) ; 
21 ouverture d'une deuxieme session tf echanges de donnees 

10 entre ladite carte a puce (2a) et au moins ledit terminal (1) pour 

transmettre lesdites donnees de parametrage de chargement au dit 
premier programme de chargement (OL), lesdites donnees de 
parametrage comportant une reference aux dites instructions associees 
au dit second programme de chargement (IL) ; et 

IS 3/ ouverture d'une troisieme session d'6changes de donn§es 

entre au moins ledit terminal (1) et ladite carte k puce (2a), pour la 
soumission d'un fichier de chargement (7) prenant en compte lesdites 
donnees de parametrage de chargement, ledit fichier comprenant des 
donn6es (70, 71 . 72) associees a ladite piece de logiciel a charger 

20 (Da) ; interpr6tation de ladite suite d'instructions associee au dit second 

programme de chargement (IL), par mise en oeuvre de ladite 
fonctionnalite "CGI", de maniere a generer une suite d*ordres transmise 
au dit second programme de chargement (IL), a executor ce 
programme (IL) et a obtenir ledit dechargement de ladite piece de 

25 logiciel (Da). 

2. Procdde selon la revendication 1 , caract§rise en ce que ledit lecteur de 
carte a puce (3) et ladite carte a puce (2a) comprennent des premiere et 
deuxieme piles protocolaires pour lesdites transmissions de donn6es 
selon ledit premier protocole determine, d6finies par la norme ISO 7816, 
30 chacune comprenant au moins des couches protocolaires de 
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communication logicielles (101, 200a), dites basses, de maniere d 
permettre lesdits ^changes de donnees entre ladite carte a puce (2a) et 
ledit terminal (1), ces couches formant interface avec lesdites premiere 
(13) et seconde (23a) pieces de logiciel sp6cifique formant lesdites 
5 couches protocolaires de communication specifiques, respectivement. et 
en ce que ces pieces de logiciel (13, 23a) comprennent chacune deux 
entites suppl§mentaires constitutes d'un module de transfert de donntes 
(130, 230a), formant interface avec lesdites couches basses (101, 200a) 
des premiere et deuxieme piles protocolaires, et d'un module de gestion 
10 (131 . 231a), et en ce que lesdites premieres entites de chaque paire sont 
constituees de modules logiciels, dits agents intelligents (132, 232a1) 
etablissant lesdites sessions. 

3. Precede selon la revendication 2, caract§rise en ce que ladite suite 
tfinstructions a interpreter associee au dit second programme (IL) de 

IS dechargement est constitute par un script et en ce que ladite deuxieme 
entite logicielle est constitute par un module logiciel dit agent intelligent 
traducteur de script {ATS^ - ATS^) fournissant des ordres comprehensibles 
par ledit second programme de chargement (OL). 

4. Precede selon la revendication 3, caracterise en ce que ladite premiere 
20 etape comprend Ttmission d'une requete de type dit "HTTP" selon un 

protocole de type Internet par adressage d'une page determinee en 
langage -HTML" contenant lesdites donnees de paramttrage, ladite 
adresse ttant une adresse de type "URL" de rebouclage sur ladite carte a 
puce (2a). 

25 5. Precede selon la revendication 4, caracterise en ce que ladite deuxieme 
etape comprend renvoi par ladite carte a puce (2a) d'un formulaire (8, 8') 
en langage "HTML" et en ce que ledit formulaire (8, 8*) comprend au 
moins une adresse de type dit "URL" de rebouclage sur ladite carte a 
puce (2a) et un chemin menant a un repertoire dttermine contenant ledit 
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script associe au dit second programme de chargement (IL), de maniere a 
ce que ce dit premier programme de chargement (OL) recupere les dites 
donnees de parametrage. 

6. Procede selon la revendication 5, caract§rise en ce que ladite troisieme 
5 6tape comprend renvoi d'une requete de type dit "HTTP" a ladite adresse 
"URL", designant ledit repertoire contenant ledit script associe au dit 
second programme de chargement (IL), ladite requete comprenant 
lesdites donnees representant ladite pidce de logiciel a charger (Da), 
rinterpr6tation dudit script et Texecution dudit second programme de 
10 chargement (OL), de maniere a obtenir ledit chargement de la dite piece 
de logiciel (Da). 

7- Procede selon la revendication 6, caracteris6 en ce que ladite piece de 
logiciel (Da) est une appliquette ecrite en langage "JAVA" (marque 
d§posee). 

15 8. Procede selon la revendication 7, caracterise en ce que ledit fichier de 
chargement (7) est incorpore dans ledit formulaire (8, 8') et comprend une 
entete (70) identifiant ladite appliquette, des donnees (71) et au moins 
une signature electronique (72) obtenue a partir du chiffrement desdites 
donnees. 

20 9. Proc6de selon la revendication 8, caractdrise en ce quNI comprend au 
moins une premiere etape supplementaire. realis6e apres ladite troisieme 
etape, et en ce que cette premiere etape supplementaire consiste en 
rouverture premiere session supplementaire d'echanges de donnees 
entre ladite carte a puce (2a) et au moins ledit terminal (1) pour 

25 transmettre un code predetermine regu par ledit premier programme de 
chargement (OL). 
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10-Proc6cl6 selon la revendication 9, caracterise en ce que ledit code 
predetermine consiste en un acxjuittement lorsque lesdites trois premieres 
§tapes se sont deroulees correctement ou un code d'erreur dans le cas 
contraire. 

11. Precede selon la revendication 10, caracterise en ce qu'il comprend au 
moins deux etapes supplementaires, realisees apres ladite troisieme 
etape, comprenant Touverture de sessions d'echanges de donn6es 
bidirectionnels entre ladite carte a puce (2a) et au moins ledit terminal (1) 
pour la transmission d'un formulaire supplementaire requ§rant la 
soumission de donnees supplementaires. 

12. Proced6 selon la revendication 11, caracterise en ce que lesdites 
donn§es supplementaires comprennent une signature electronique 
supplementaire. 

13. Procede selon la revendication 12, caracterise en ce que ledit terminal 
etant connecte a au moins un serveur eloigne (4) via un reseau de type 
Internet (Rl) et par la mise en oeuvre de protocole de communication de 
type Internet, un desdits agents intelligents (132) est associe a un attribut 
dit de "r§seau" permettant des communications avec ledit reseau Internet 
{Rl) et en ce que ledit premier programme de chargement (OL) est stocke 
sur Tun desdits serveurs eloignes (4, 4a). 

14. Proc6de selon la revendication 13, caracterise en ce que, ledit terminal 
(1) comprenant un navigateur de type "WEB" (10), ledit premier 
programme de chargement (OU) est constitue par un composant logiciel 
dudit navigateur "WEB" (10). 

15. Procede selon la revendication 14, caracterise en ce que ledit composant 
logiciel (OL") est obtenu par une etape initiate de chargement dynamique 
d'une appliquette (OL) ecrite en langage "JAVA" et stockee dans ladite 
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carte k puce (2a), ledit chargement etant obtenu par remission d'une 
requete de type "HTTP", avec un adressage de type "URL" de ladite carte 
a puce (2a). 

16. Precede selon la revendication 17, caracterise en ce que ledit composant 
5 logiciel (OL") est obtenu par une etape initiate de chargement dynamique 
d'une appliquette (OL) ecrite en langage "JAVA" et stockee dans un 
desdits serveurs eloignes (4), ledit chargement etant obtenu par remission 
d'une requete de type "HTTP", avec un adressage de type "URL" dudit 
sen/eur 6loigne (4). 
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